Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/sdd/design/chrome-sidecar/components/chrome-sidecar-service.md`:
- Line 9: 行内のカンマ区切りで並んでいる要件識別子（例: REQ-001-001, REQ-001-002, REQ-001-004,
REQ-002-001, REQ-002-002, REQ-004-001, NFR-SEC-001, NFR-SEC-002, NFR-RES-001,
NFR-RES-002,
NFR-RES-003）を1行の長いカンマ列からマークダウンの箇条書き（あるいは改行されたリスト）に置き換えてください；具体的には当該行を削除して各識別子を各行先頭にハイフンまたは番号付きリスト記号を付けて分割し、README/ドキュメントの他のリストと一致する書式（例:
"- REQ-001-001"）に揃えてください。

In `@docs/sdd/design/chrome-sidecar/components/db-schema.md`:
- Around line 105-106: ドキュメントの chromeSidecar.image
の正規表現が実装と食い違っているため、ドキュメントを実装ルールに合わせて修正してください：chromeSidecar.image
の説明と正規表現を、レジストリポートで使用するポート表記を許可する形に更新し、現在の `[-a-z0-9._/]+` からコロン `:`
を許可する正規表現（例としてポートを含められる形）や説明文を反映させてください（参照シンボル：chromeSidecar.image）。

In `@docs/sdd/design/chrome-sidecar/components/environment-ui.md`:
- Around line 50-56: The design says to remove the chromeSidecar key from the
saved config when the sidecar toggle is OFF, but the implementation in
src/components/projects/ProjectEnvironmentSection.tsx currently writes
chromeSidecar: { enabled: false }; fix by updating the save/serialize logic in
ProjectEnvironmentSection (the handler that builds the config JSON) to omit the
chromeSidecar property entirely when the toggle is false (instead of setting
enabled: false); ensure any helper that merges config or functions named like
buildConfig/saveEnvironment respect this omission and update related tests or
API consumers to expect absence of chromeSidecar rather than an enabled:false
entry, or alternatively update the design doc to match the current
implementation if you prefer keeping enabled:false.

In `@server.ts`:
- Around line 337-345: Replace the direct instantiation new
ChromeSidecarService() with the singleton accessor
ChromeSidecarService.getInstance() so the startup path uses the same singleton
as the rest of the app; obtain the instance via
ChromeSidecarService.getInstance(), then call await instance.cleanupOrphaned()
and keep the existing try/catch and logger.error/logger.info calls (references:
ChromeSidecarService.getInstance, ChromeSidecarService.cleanupOrphaned, logger).

In `@src/components/environments/ChromeSidecarSection.tsx`:
- Around line 34-48: The checkbox inside ChromeSidecarSection lacks an
accessible name; update the input (the checkbox element that uses
checked={enabled}, onChange={(e) => onEnabledChange(e.target.checked)},
disabled={disabled}) to provide one—either add aria-label="Enable Chrome
Sidecar" (or a localized string) or add aria-labelledby linking to the section
heading (give the h5 a unique id and set input aria-labelledby to that id) so
screen readers can announce the control; ensure the chosen string clearly
conveys the toggle purpose and keep the existing label wrapper/visual markup
unchanged.

In `@src/components/projects/ProjectEnvironmentSection.tsx`:
- Around line 155-160: When restoring chromeSidecar settings in
ProjectEnvironmentSection, explicitly reset state to defaults whenever
config.chromeSidecar is missing, parse fails, or the environment/container type
is not DOCKER: call setChromeSidecarEnabled(false), setChromeSidecarImage('')
and setChromeSidecarTag('') instead of leaving previous values; likewise update
the other restore/parse block that touches chromeSidecar to do the same. Ensure
saving/serialization logic only writes image/tag when chromeSidecar is enabled
so stale values are not persisted.

In `@src/lib/chrome-sidecar-validator.ts`:
- Around line 16-24: The code treats any falsy chromeSidecar as "not set" and
lets invalid values like false/0/'' pass; change the existence check to
distinguish "key not present" from "present but falsy": first check if config
hasOwnProperty('chromeSidecar') or use 'chromeSidecar' in config to decide if
it's provided; then ensure chromeSidecar is an object (typeof chromeSidecar ===
'object' && chromeSidecar !== null) before casting to sidecar; finally validate
sidecar.enabled exists and is a boolean (and keep the early return when
sidecar.enabled === false), referencing the config/chromeSidecar variable and
the sidecar.enabled check in your existing logic.

In `@src/services/__tests__/chrome-sidecar-cleanup-integration.test.ts`:
- Around line 63-78: The test sets serverStarted = true unconditionally, so it
cannot detect whether cleanupOrphaned swallowed the Docker ENOENT error; update
the test for ChromeSidecarService.cleanupOrphaned to (1) remove the
unconditional assignment and instead set a flag only when execution reaches the
post-call path or assert that the call does not throw (e.g., await
expect(sidecarService.cleanupOrphaned()).resolves.toBeUndefined()), and (2)
verify logger.error behavior by asserting logger.error was (or was not) called
as intended (use mock/spy on logger.error and
expect(mockedLogger.error).toHaveBeenCalledWith(...) or toHaveBeenCalledTimes(0)
depending on desired behavior). Also keep the
mockCleanupOrphaned.mockRejectedValueOnce call to simulate the ENOENT error.

In `@src/services/adapters/__tests__/docker-adapter-chrome-sidecar.test.ts`:
- Around line 30-240: The tests currently call mocks directly or reimplement
logic, so they don't exercise the real control flow; change the spec to invoke
DockerAdapter.createSession and DockerAdapter.destroySession (and
PTYSessionManager.createSession where applicable) instead of calling
mockStartSidecar/mockStopSidecar or reimplementing injectBrowserUrl logic, and
mock the external dependencies (DockerClient, DB, ChromeSidecarService) to
return controlled values—specifically stub ChromeSidecarService.startSidecar,
ChromeSidecarService.stopSidecar, and DockerAdapter.connectClaudeContainer (or
DockerClient methods) while asserting the adapter/manager methods call those
services and produce the expected behavior and error-handling (graceful
degradation) rather than asserting on the mocks directly.

In `@src/services/adapters/docker-adapter.ts`:
- Around line 1001-1017: The DB write for chrome_container_id/debug_port can
fail and later teardown (destroySession) relies solely on the DB, so modify the
DockerAdapter flow to also persist the sidecar identifiers directly on the
in-memory DockerSession object (e.g., set DockerSession.containerName and
DockerSession.networkName and debugPort) immediately after sidecar creation, and
ensure destroySession() reads these properties first (falling back to the DB
only if they are absent); update the code paths around the DB update (the
try/catch block that updates schema.sessions) to still log the error but keep
the in-memory DockerSession populated so teardown can always find the container
even if the DB write failed.
- Around line 841-865: createSession starts the Chrome sidecar via
ChromeSidecarService.startSidecar (producing sidecarResult and container/network
named with sessionId) but never calls stopSidecar on subsequent failures,
leaking cw-chrome-<sessionId> and cw-net-<sessionId>; wrap the code that runs
after startSidecar (the createContainer/attach/start/waitForContainerReady/DB
update sequence) in a try/catch/finally (or ensure a Promise.finally) so that on
any exception or non-success path you call
ChromeSidecarService.getInstance().stopSidecar(sessionId, sidecarResult) (only
if sidecarResult is set) to tear down container/network, and apply the same fix
to the other occurrence around the block at lines ~1150-1156 to guarantee
cleanup on all failure paths.

---

Nitpick comments:
In `@docs/sdd/design/chrome-sidecar/api/environment-api.md`:
- Line 45: The validation regex for chromeSidecar.image currently listed as
`/^[-a-z0-9._/]+$/` rejects colon characters used for registry ports/tags;
update the pattern referenced for chromeSidecar.image to allow colons (add ':'
to the allowed character class) and update the associated error message (the
string describing allowed characters, e.g., "lowercase alphanumeric, dots,
slashes, hyphens") to mention colons (or "ports/tags") so the docs and message
reflect the new acceptance of colon-separated registry:port formats.

In `@docs/sdd/design/chrome-sidecar/components/chrome-sidecar-service.md`:
- Around line 185-229: The design doc's CDP health-check block (waitForCDP)
currently shows docker exec + wget but the real implementation in
chrome-sidecar-service.ts uses host-port fetch; update the design: either
replace the code example in waitForCDP with the host-port fetch implementation
pattern (using fetch against the mapped host port or network IP) and remove the
wget-centric assumption, or keep the wget example but move the current note into
the main implementation section and explicitly document the alternate host-port
fetch approach used in chrome-sidecar-service.ts (include function name
waitForCDP and file chrome-sidecar-service.ts as references) so design and code
remain consistent.

In `@docs/sdd/design/chrome-sidecar/index.md`:
- Around line 7-25: The fenced ASCII art block in index.md triggers markdownlint
MD040; update the code fence that wraps the Session起動フロー ASCII diagram to
include a plain text language tag (e.g., use ```text or ```plaintext) so the
block is explicitly marked as non-code and the linter warning is
suppressed—locate the ASCII diagram block (the fenced block containing
"Session起動フロー (サイドカー有効時):" and the diagram) and add the language identifier to
the opening fence.

In `@docs/sdd/design/chrome-sidecar/sequences/session-teardown.md`:
- Around line 13-68: Add a language specifier "text" to the fenced sequence
diagram code block (the triple-backtick block that starts with the diagram
header line "Client          PTYSessionMgr     DockerAdapter ...") to silence
markdownlint MD040; update the opening fence from ``` to ```text (and apply the
same change to any other similar fenced-diagram blocks in session-teardown.md)
so the diagram remains unchanged but is explicitly marked as plain text.

In `@src/app/api/environments/__tests__/chrome-sidecar-validation.test.ts`:
- Around line 6-103: Add tests to cover cases where chromeSidecar key exists but
is not an object (e.g., chromeSidecar: false, 0, '', []) by calling
validateChromeSidecarConfig with each and asserting the returned error is not
null and mentions "chromeSidecar" (or "chromeSidecar.enabled" depending on
current error text); locate the test block using the existing describe for
chrome-sidecar validation and the validateChromeSidecarConfig calls to add these
new it(...) cases to prevent regressions for non-object types.

In `@src/app/api/projects/`[project_id]/environment/route.ts:
- Around line 216-228: The code duplicates computation of effectiveType (using
type ?? existing.type) in multiple places; compute effectiveType once at the
start of the config validation block and reuse it for all subsequent checks
(including the DOCKER-only chromeSidecar call), then remove the second
calculation to improve readability—update references in the chromeSidecar
validation to use the single effectiveType and ensure
validateChromeSidecarConfig(sanitizedConfig) remains unchanged.

In `@src/app/api/sessions/__tests__/chrome-sidecar-response.test.ts`:
- Around line 120-133: The test currently just spreads dbResult into response
(const response = { ...dbResult }) which doesn't exercise the API logic; change
the spec to call the real GET handler for /api/sessions/:id (or invoke the
exported GET function from the sessions route) while mocking the Drizzle query
to return dbResult, then assert the JSON response contains chrome_container_id
and chrome_debug_port; update the test in chrome-sidecar-response.test.ts to
remove the self-validation and perform an actual GET call (or handler
invocation) with the mocked DB so the conversion logic is exercised and
regressions are caught.

In `@src/components/environments/__tests__/chrome-sidecar-form.test.tsx`:
- Around line 1-72: Add two unit tests in the existing
chrome-sidecar-form.test.tsx to assert that ChromeSidecarSection calls the
provided callbacks when inputs change: render ChromeSidecarSection with
enabled={true} and a mock onImageChange, simulate changing the "Chrome Image"
input (fireEvent.change) and expect onImageChange
toHaveBeenCalledWith('new-image'); similarly render with a mock onTagChange,
change the "Chrome Tag" input and expect onTagChange
toHaveBeenCalledWith('132.0.0.0'); use the existing defaultProps and
screen.getByLabelText to locate inputs and vi.fn() for mocks.

In `@src/components/sessions/ChromeDebugInfo.tsx`:
- Around line 28-34: The code currently treats chromeDebugPort as truthy/falsy
which will treat 0 as unavailable; change both checks to explicit null
comparisons (use chromeDebugPort !== null for the ternary that shows 'Running'
vs 'Running (debug port unavailable)' and for the conditional rendering that
shows the debug-port div) so that a port value of 0 is handled according to the
type intent and only null indicates "unavailable."

In `@src/services/__tests__/chrome-sidecar-cleanup-integration.test.ts`:
- Around line 35-40: The test currently calls
ChromeSidecarService.cleanupOrphaned() directly which lets regressions in the
real startup flow pass unnoticed; change the test to exercise the actual startup
flow (or an extracted startup helper) used in server.ts so it will fail if
server.ts stops calling cleanupOrphaned. Specifically, locate the server startup
entry (e.g., exported startServer/initServer/bootstrap function) and invoke that
in the test instead of new ChromeSidecarService().cleanupOrphaned(), keep or
inject the same mock for ChromeSidecarService.cleanupOrphaned, and assert the
mock was called; ensure any required bootstrapping dependencies are
stubbed/mocked so the startup function can run in the test.

In `@src/services/chrome-sidecar-service.ts`:
- Around line 433-447: The loop can double-wait because fetch is aborted after
interval and then you always sleep for interval; update the loop in
chrome-sidecar-service.ts (symbols: startTime, timeoutMs, interval, controller,
fetchTimeout) so each iteration enforces a single interval period: record
iterationStart before creating the AbortController, set the fetch timeout to
abort after the full desired fetch window, await fetch, then compute elapsed =
Date.now() - iterationStart and only sleep for Math.max(0, interval - elapsed)
before the next iteration; this ensures total time per loop is ~interval rather
than ~2*interval while keeping the existing timeoutMs logic intact.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/sdd/design/chrome-sidecar/components/chrome-sidecar-service.md`:
- Around line 234-249: The fenced code block containing the startup steps (the
block starting with "サーバー起動時:" in chrome-sidecar-service.md) lacks a language
tag and triggers MD040; update the opening fence from ``` to a
language-specified fence such as ```text (or another appropriate language) so
the code block becomes ```text ... ``` and the linter warning is resolved.
- Around line 210-214:
ドキュメント内のコード例が実装と乖離しているので、DockerClient.getInstance().getContainer(...)/container.exec(...)での
wget 実行例を削除し、実装で使っているホスト側ポート経由の HTTP GET ポーリング方式（Node.js の fetch または http.get
を用いるロジック）に差し替えてください。具体的には DockerClient.getInstance().getContainer と
container.exec を参照する箇所を見つけ、コンテナ内コマンド実行例ではなく、ホストの
http://localhost:9222/json/version
に対するポーリング（リトライ、タイムアウト、レスポンスチェック）を行う擬似コード例に置き換え、230行の注記と整合する説明に更新してください。

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/sdd/design/chrome-sidecar/components/db-schema.md`:
- Line 115: The sentence about backward compatibility is ambiguous: update the
wording that references DockerAdapterConfig and AdapterFactory so it states they
ignore the chromeSidecar key only when that key is absent (i.e., treat
chromeSidecar as disabled if not present), not that they always ignore it;
replace the phrase "chromeSidecar キーを無視する" with a precise clause like
"chromeSidecar が未設定の場合のみ無効扱い（明示的に設定・参照される場合は従う）" and ensure DockerAdapterConfig
and AdapterFactory are explicitly mentioned as honoring an explicitly set
chromeSidecar.

---

Duplicate comments:
In `@src/components/projects/ProjectEnvironmentSection.tsx`:
- Around line 155-177: The chromeSidecar state can leak because only the
config.chromeSidecar true/false branch resets it; ensure you deterministically
reset chrome sidecar state in every control path (env.type !== 'DOCKER' branch,
missing env.config branch, and the catch block for JSON parse). Update the logic
around the try/catch in the ProjectEnvironmentSection component so that
setChromeSidecarEnabled, setChromeSidecarImage, and setChromeSidecarTag are
always called with explicit defaults when Docker config is absent or parse fails
(rather than leaving previous values), keeping the existing restore behavior
when config.chromeSidecar exists; reference the existing setters
setChromeSidecarEnabled, setChromeSidecarImage, setChromeSidecarTag and the
try/catch block that sets initialConfigRef.current.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/sdd/design/chrome-sidecar/sequences/session-startup.md`:
- Line 13: Add a language identifier (e.g., "text") to all fenced code blocks
that currently lack one in this document—specifically the sequence diagram/code
fences that start with role lines like "Client          PTYSessionMgr    
DockerAdapter     ChromeSidecarSvc    DockerClient" and the similar blocks
containing "DockerAdapter     ChromeSidecarSvc    DockerClient"; update each
opening ``` to ```text so markdownlint MD040 is resolved (apply same change to
the other occurrences mentioned in the review).

---

Nitpick comments:
In `@src/lib/chrome-sidecar-validator.ts`:
- Around line 41-43: Remove the redundant typeof check in the conditional that
rejects "latest": since you already validate typeof sidecar.tag !== 'string'
earlier, simplify the if to directly test sidecar.tag.trim().toLowerCase() ===
'latest' and return the same error message ("chromeSidecar.tag must be a
specific version (latest is not allowed for reproducibility)"); update the
conditional around sidecar.tag so it relies on the prior type guard and does not
repeat typeof sidecar.tag === 'string'.
- Around line 33-35: The error message for the image validation in
chrome-sidecar-validator.ts is inconsistent with the regex: the pattern for
sidecar.image (checked in the if that tests typeof sidecar.image and
/^[-a-z0-9._/:]+$/) allows underscores but the message does not mention them;
update the returned string in that validation branch to list underscores (e.g.,
include "underscore") or otherwise match the regex (or alternatively remove `_`
from the regex) so the message and the regexp agree, referencing the
sidecar.image validation in chrome-sidecar-validator.ts.

In `@src/services/adapters/docker-adapter.ts`:
- Around line 984-1047: The review notes that when
ChromeSidecarService.connectClaudeContainer (used here) or the DB update fails
we best-effort stop the sidecar while the Claude container remains running and
.mcp.json already has browserUrl injected, causing MCP clients to attempt
connecting to a non-existent chrome-devtools endpoint; document this
graceful-degradation behavior. Update the operational/README (or runbook) to
explain: where ChromeSidecarService.connectClaudeContainer and stopSidecar are
invoked, that .mcp.json/browserUrl may be present even if sidecar cleanup
occurred, the observable symptoms (MCP connection errors with sessionId),
recommended troubleshooting steps (check logs for logger.warn entries, verify
container existence, inspect session DB fields
chrome_container_id/chrome_debug_port), and suggested mitigation (re-run sidecar
or restart session). Ensure the doc references the functions
ChromeSidecarService.connectClaudeContainer, ChromeSidecarService.stopSidecar
and the DB fields chrome_container_id/chrome_debug_port so operators can
correlate logs and state.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/services/adapters/__tests__/docker-adapter-chrome-sidecar.test.ts`:
- Line 247: The variable mockContainer created by calling setupContainerMock()
is unused and causes a no-unused-vars lint failure; either remove the assignment
statement entirely or, if the mock was intended for later use, reference it
where needed (e.g., pass mockContainer into the test helper or assertion).
Locate the unused declaration `const mockContainer = setupContainerMock()` in
the test and either delete that line or update the test to use `mockContainer`
(or rename to _mockContainer to indicate intentional unused) so the linter error
is resolved.